The present invention relates to the field of portal development tools and, more particularly, to dynamically adaptive portlet palette having user/context customized and auto-populated content.
Portals are containers that contain customizable portlets, each of which is linked to a portlet specific data source. To customize a portal, users access a portlet palette, which contains a listing of available portlets. The user can select (e.g., drop-and-drag) portlets from the palette and place them on the customizable portal, to add the portlet to the portal. Existing portlet palettes can provide a static listing of default portlets that is presented to all users and/or can provide an ability to manually modify the portlets provided within the palette. Current portlet palettes do not automatically adapt to user or request context.
FIG. 1 (Prior Art) is a schematic diagram of a view of a typical portal server 100 implementation. The portal server 100 includes logical components for user authentication 105, state handling 110, and aggregation 115 of fragments, a set of portlets 120, portlet container software 135, portal storage resources 140, and the like. The logic components are operatively connected such that data can be exchanged between single components as required. The server 100 can realizes a request/response communication pattern (i.e. it can waits for client requests and responds to these requests). A client request message can include a Uniform Resource Locator (URL)/Uniform Resource Identifier (URI) which addresses the requested portal page and/or other portal resources.
Server 100 can include a manual layout interface 160, a model management component 161, and a portal palette 165. Portlet palette 165 can be a graphical representation of a set of portlets 120 that a user can add to a portal page 125 through user interactions. The portlet palette 165 can be easier for many users to utilize than the manual layout interface 160, which results in palette 165 being a preferred interface for customizing portals.
FIG. 2 (Prior Art) shows a data flow 200 of interactions in a portal during render request processing. Illustrated interactions involve a client 210, a portal 212, a portal container 214, and a set of portlets 216 A, B, and C. In flow 200, client 210 can issues a request 220 (e.g., for a new page). For example, a user can click on a link for creating a new page, where the link can be displayed in a portal configuration browser window. The portal 212 can receive the request 220 that invokes state handling and conveys the request 222 to portal container 214. The state handling operations can determine the aggregation state and the portlet state that is encoded in/associated with the URL. The portal container 214 can perform an aggregation check to see if a derived page exists for a current user. A page can be loaded according to a page definition obtained from the portal database. The portlets 216 referenced in this page definition (i.e. that are contained on the page) can be determined. A render request 224 can be sent to each determined portlet 216. Each portlet (Portlet A, B and C) can create its own markup independently and can return the markup fragment within a request response 226. The responses 226 can be conveyed through container 214 to portal 212. The portal 212 can provide 228 a browser render able portal page to client 210.